darwin.Libsystem: fix existing file error during build#237348
darwin.Libsystem: fix existing file error during build#237348toonn merged 7 commits intoNixOS:stagingfrom
Conversation
Some of the headers are symlinked to the root `include` in upstream Libsystem, so also symlink them there from `include/pthread`.
ofborg
bot
added
10.rebuild-darwin-stdenv
ofborg
bot
requested review from
LnL7,
copumpkin,
gridaphobe,
matthewbauer and
shlevy
ofborg
bot
added
10.rebuild-darwin: 501+
A number of headers in Libc are being vendored from other packages. Instead of copying them from an earlier Libc, Libsystem now sources them from their respective packages (see below). This allows Libc_old to be dropped and avoids any potential clashes when building Libsystem. libmalloc: * malloc/malloc.h libplatform: * setjmp.h * ucontext.h * libkern/OSAtomic.h * libkern/OSCacheControl.h libpthread: * pthread*.h * sched.h * spawn.h syslog (vendored because only one file is needed): * asl.h xnu: * spawn.h (a different one from libpthread) * libproc.h
reckenrode
force-pushed
the
darwin-libc-cleanup
branch
from
5303924 to
23cb6c1
Compare
toonn
left a comment
toonn
left a comment
There was a problem hiding this comment.
To reproduce the error we need to rebuild darwin.Libsystem with Coreutils 9.3. These aren't an explicit dependency but come from stdenv. As reckenrode pointed out, the stdenv, probably erroneously, inherits Coreutils from the previous stage in each stage. This means stdenv just has the Coreutils from the bootstrap tarball at the point where darwin.Libsystem gets built. The final stdenv does have the proper Coreutils tools but similarly inherits darwin.Libsystem so it never ends up being built with the latest Coreutils.
However, since the final stdenv does have the correct version of Coreutils we can just rebuild against that, nix-build --pure --no-out-link -E 'with (import ./. {}); darwin.Libsystem.override { inherit stdenv; }.
reckenrode
changed the title
|
@toonn I updated the PR to reflect that this is a Libsystem issue caused by Libc rather than a Libc issue alone. I also tested using the command you provided and can confirm it reproduces the error using the current stdenv. $ nix-build --pure --no-out-link -E 'with (import ./. {}); darwin.Libsystem.override { inherit stdenv; }' --system x86_64-darwin
@nix { "action": "setPhase", "phase": "unpackPhase" }
unpacking sources
unpacking source archive /nix/store/85zm06baw94yi7cz4nmr9yynqdrsigcw-Libsystem-1238.60.2.tar.gz
source root is Libsystem-Libsystem-1238.60.2
setting SOURCE_DATE_EPOCH to timestamp 1633495754 of file Libsystem-Libsystem-1238.60.2/xcodescripts/linker_arguments.sh
@nix { "action": "setPhase", "phase": "patchPhase" }
patching sources
@nix { "action": "setPhase", "phase": "configurePhase" }
configuring
no configure script, doing nothing
@nix { "action": "setPhase", "phase": "installPhase" }
installing
cp: not replacing '/nix/store/g65n8z3fgvy8dld580d53nqakv43g7ka-Libsystem-1238.60.2/include/./setjmp.h' |
3 participants
Description of changes
After coreutils was updated in #222314, darwin.Libsystem began failing to build in the rework. This appears to be due to a changing in behavior of
cp -nto return a non-zero exit code when a file already exists. Note this only affects the reworked stdenv because the current one builds Libsystem with coreutils from the bootstrap tools.Testing was done with a build of the reworked stdenv bootstrap. For aarch64-darwin, I manually built darwin.libmalloc and confirmed it was building from the newer version. Since aarch64-darwin is not building a source SDK, these headers are not used, but it is ready if/when that it does.
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)